Okay, I don't really know much about the automap code, but this seems and works fine code-wise. But I feel like the way to not draw path lines when the player teleports is kinda flawed. It does not account for short distance teleports, like say a teleporter that just transports you to the other side of a wall, and so lines are drawn between teleport positions anyway.

Cool. If I were you, I'd use int16_t to store the coordinates, since double seems like an overkill.

It does not account for short distance teleports, like say a teleporter that just transports you to the other side of a wall, and so lines are drawn between teleport positions anyway.

I've set the distance threshold pretty high while testing. It can probably be decreased as even full-speed SR50 isn't quite close to this distance threshold (in terms of distance travelled per tick).

Edit: I've reduced the distance threshold for teleport detection from 300 to 100 units. I've tested Doom 2 MAP12 with compatflags 64 (Enable wall running) and can confirm that line is still drawn correctly when you wallrun and SR50 on the outer walls, even if you also keep firing rockets backwards to propel yourself at the same time.

If I were you, I'd use int16_t to store the coordinates, since double seems like an overkill.

There doesn't appear to be a built-in type for points with int16_t, and I'm not sure if I should introduce one here just for this feature. Also, large maps may have coordinates outside the [-32768; 32767] range. While fline_t could be used here for 32-bit integer coordinates, it will require a bunch of casting when drawing, so any performance gains may not be noticeable.

It does not account for short distance teleports, like say a teleporter that just transports you to the other side of a wall, and so lines are drawn between teleport positions anyway.

I've set the distance threshold pretty high while testing. It can probably be decreased as even full-speed SR50 isn't quite close to this distance threshold (in terms of distance travelled per tick).

Edit: I've reduced the distance threshold for teleport detection from 300 to 100 units. I've tested Doom 2 MAP12 with compatflags 64 (Enable wall running) and can confirm that line is still drawn correctly when you wallrun and SR50 on the outer walls, even if you also keep firing rockets backwards to propel yourself at the same time.

Yeah that works a lot better, by the way, if you wanna test something involving player speed, I'd suggest using the turbo 255 command, since it's much faster than rocket jumping or wallrunning.

If I were you, I'd use int16_t to store the coordinates, since double seems like an overkill.

There doesn't appear to be a built-in type for points with int16_t, and I'm not sure if I should introduce one here just for this feature. Also, large maps may have coordinates outside the [-32768; 32767] range. While fline_t could be used here for 32-bit integer coordinates, it will require a bunch of casting when drawing, so any performance gains may not be noticeable.

That ain't happening, 65535x65535 map units is the maximum size limit for any Doom maps except for the ones in Sonic Robo Blast 2, where IIRC they doubled the map size limit

Instead, what you should do is see if the delta distance between tics is greater than the player's velocity. This would be a much more reliable way to check for teleport shenanigans since - in some cases - velocity can be arbitrary. As a general rule, always whenever possible, avoid arbitrary static numbers, especially in a moddable engine.

I've tried my hand at implementing this in a second commit (which also fixes a compilation warning related to signed type comparison). It works mostly OK from my testing. One issue is that bumping into a wall and backing up will cause the line to be missing one point:

PS: Doom E2M4 is a good place to test this code, as it has a teleport near the starting area.

Any more progress or info on this PR?